Evolved Universal Terrestrial Radio Access Acknowledged Mode Radio Link Control Status Report for Segmented Protocol Data Units

ABSTRACT

A method is provided for an acknowledged mode (AM) radio link control (RLC) receiving entity to promote a retransmission of at least a segment of a data protocol data unit (PDU). The method comprises the receiving entity constructing a STATUS PDU such that an AM RLC transmitting entity receiving the STATUS PDU retransmits the segment.

BACKGROUND

As used herein, the terms “user equipment” and “UE” can refer towireless devices such as mobile telephones, personal digital assistants,handheld or laptop computers, and similar devices that havetelecommunications capabilities. Such a UE might consist of a wirelessdevice and its associated Universal Integrated Circuit Card (UICC) thatincludes a Subscriber Identity Module (SIM) application, a UniversalSubscriber Identity Module (USIM) application, or a Removable UserIdentity Module (R-UIM) application or might consist of the deviceitself without such a card. The term “UE” may also refer to devices thathave similar wireless capabilities but that are not transportable, suchas desktop computers, set-top boxes, or network nodes. When a UE is anetwork node, the network node could act on behalf of another functionsuch as a wireless device and simulate or emulate the wireless device.For example, for some wireless devices, the IP (Internet Protocol)Multimedia Subsystem (IMS) Session Initiation Protocol (SIP) client thatwould typically reside on the device actually resides in the network andrelays SIP message information to the device using optimized protocols.In other words, some functions that were traditionally carried out by awireless device can be distributed in the form of a remote UE, where theremote UE represents the wireless device in the network. The term “UE”can also refer to any hardware or software component that can terminatea SIP session.

In traditional wireless telecommunications systems, transmissionequipment in a base station transmits signals throughout a geographicalregion known as a cell. As technology has evolved, more advanced networkaccess device has been introduced that can provide services that werenot possible previously. This advanced network access device mightinclude, for example, an evolved node B (eNB) rather than a base stationor other systems and devices that are more highly evolved than theequivalent equipment in a traditional wireless telecommunicationssystem. Such advanced or next generation equipment may be referred toherein as long-term evolution (LTE) equipment, and a packet-basednetwork that uses such equipment can be referred to as an evolved packetsystem (EPS). As used herein, the term “access device” will refer to anycomponent, such as a traditional base station, an LTE eNB, or any othersystem or device, that can provide a UE with access to other componentsin a telecommunications system.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of this disclosure, reference is nowmade to the following brief description, taken in connection with theaccompanying drawings and detailed description, wherein like referencenumerals represent like parts.

FIG. 1 is a block diagram of a PDU packet transmission procedureaccording to an embodiment of the disclosure.

FIG. 2 is a table of state variables maintained by a transmitting entityin a PDU packet transmission procedure according to an embodiment of thedisclosure.

FIG. 3 is an example of an RLC transmitting window according to anembodiment of the disclosure.

FIG. 4 is a table of state variables maintained by a receiving entity ina PDU packet transmission procedure according to an embodiment of thedisclosure.

FIG. 5 is an example of an RLC receiving window according to anembodiment of the disclosure.

FIG. 6 is a diagram of a STATUS PDU according to an embodiment of thedisclosure.

FIG. 7 is a table of descriptions of fields in a STATUS PDU according toan embodiment of the disclosure.

FIG. 8 is an illustration of the status of the receiver buffer showingan RLC PDU with a segment that was not received correctly according toan embodiment of the disclosure.

FIG. 9 illustrates a method for an acknowledged mode radio link controlreceiving entity to promote the retransmission of a segment of a dataprotocol data unit according to an embodiment of the disclosure.

FIG. 10 illustrates an alternative method for an acknowledged mode radiolink control receiving entity to promote the retransmission of a segmentof a data protocol data unit according to an embodiment of thedisclosure.

FIG. 11 illustrates a method for an acknowledged mode radio link controltransmitting entity to promote the retransmission of a segment of a dataprotocol data unit according to an embodiment of the disclosure.

FIG. 12 illustrates an alternative method for an acknowledged mode radiolink control receiving entity to promote the retransmission of a segmentof a data protocol data unit according to an embodiment of thedisclosure.

FIG. 13 illustrates an alternative method for an acknowledged mode radiolink control receiving entity to promote the retransmission of a segmentof a data protocol data unit according to an embodiment of thedisclosure.

FIG. 14 illustrates an alternative method for an acknowledged mode radiolink control receiving entity to promote the retransmission of a segmentof a data protocol data unit according to an embodiment of thedisclosure.

FIG. 15 illustrates an alternative method for an acknowledged mode radiolink control receiving entity to promote the retransmission of a segmentof a data protocol data unit according to an embodiment of thedisclosure.

FIG. 16 illustrates a processor and related components suitable forimplementing the several embodiments of the present disclosure.

DETAILED DESCRIPTION

It should be understood at the outset that although illustrativeimplementations of one or more embodiments of the present disclosure areprovided below, the disclosed systems and/or methods may be implementedusing any number of techniques, whether currently known or in existence.The disclosure should in no way be limited to the illustrativeimplementations, drawings, and techniques illustrated below, includingthe exemplary designs and implementations illustrated and describedherein, but may be modified within the scope of the appended claimsalong with their full scope of equivalents.

The Evolved Universal Terrestrial Radio Access (E-UTRA) Radio LinkControl (RLC) protocol is described in the 3rd Generation PartnershipProject (3GPP) Technical Specification (TS) 36.322. This protocolspecifies the Layer 2 retransmission protocol for use in E-UTRA systems.The RLC protocol has three modes of operation: Acknowledged Mode (AM),Unacknowledged Mode (UM) and Transparent Mode (TM). The discussionherein relates to the AM mode of operation, wherein entities sendacknowledgements and negative acknowledgements to each other andretransmit data when necessary. The protocol is defined between peer AMRLC entities that might reside in an access device and a UE. Each peerRLC entity has a receiving side and a transmitting side.

When an RLC Protocol Data Unit (PDU) needs to be retransmitted, it ispossible for the PDU to be segmented and for each RLC PDU segment to beretransmitted separately. This may be necessary if the radio linkquality has worsened since the previous transmission of the RLC PDU andwill no longer support the transmission of same sized RLC PDU, or if theavailable amount of transmission resources has been reduced, for examplebecause of heavier cell loading.

The receiving side of an RLC entity generates RLC STATUS reports andsends them to the transmitting side of the peer RLC entity. The RLCSTATUS reports indicate the sequence numbers (SNs) of RLC PDUs that havebeen received correctly and incorrectly. If an RLC PDU has beensegmented, the RLC STATUS report indicates which segments of the RLC PDUhave been received correctly and incorrectly. After receiving an RLCSTATUS report, the transmitting side of the peer RLC entity retransmitsany RLC PDUs and/or RLC PDU segments that the receiving side did notreceive. This process of the receiving side stating in the STATUS reportthe PDUs and/or PDU segments that were not received and the transmittingside retransmitting those PDUs and/or PDU segments might continue untilthe receiving side receives all of the transmitted PDUs and PDUsegments.

This process is illustrated in the simplified block diagram shown inFIG. 1. New RLC Service Data Units (SDUs) are queued up at atransmitting RLC entity 110, which might be in a UE or in an accessdevice. As transmission opportunities arise, RLC PDUs are constructedfor transmission. At the same time, these RLC PDUs are saved in aretransmission buffer 112 in case they need to be resent. Any RLC PDUsthat are negatively acknowledged by a receiving RLC entity 120, whichmight be in a UE or in an access device, will then be retrieved from theretransmission buffer 112 and retransmitted. Received RLC PDUs arestored in a reception buffer 122 at the receiving RLC entity 120, whichperiodically and/or upon request by the transmitting RLC entity 110provides feedback in the form of STATUS reports to indicate which RLCPDUs have and have not been successfully received.

3GPP TS 36.322 specifies that the state variables described in the tablein FIG. 2 are to be maintained by the transmitting side of an AM RLCentity for AMD PDU (re)transmission purposes. The term AMD PDU in thetable refers to an AM RLC Data PDU. The transmitting window size(AM_Window_Size) is equal in length to half of the total sequence numberspace. AM RLC uses 10-bit sequence numbers, which results in anAM_Window_Size value of 512. All arithmetic operations and comparisonson RLC sequence numbers are performed using an appropriate moduluscorresponding to the configured sequence number range (i.e., 1024 for10-bit AM RLC sequence numbers) and a modulus base calculated as afunction of certain state variables and constants. This process isdescribed in 3GPP TS 36.322.

FIG. 3 shows an example AM RLC transmitting window 310, as defined bythe state variables described in the table in FIG. 2. To keep thisexample simple, a 5-bit sequence number (rather than the 10-bit AMsequence number) is assumed. Boxes 0-6 in the diagram represent RLC PDUsthat have been transmitted and acknowledged and that now fall outsidethe transmitting window 310. Boxes 8, 9, 10, 12, 14, 15, and 17represent RLC PDUs that have been transmitted and acknowledged, butwhich still fall inside the transmitting window 310. Boxes 13 and 16represent RLC PDUs that have been transmitted but which were negativelyacknowledged (and hence require Layer 2 retransmission). Boxes 7 and 11represent RLC PDUs that have been transmitted and that have some PDUsegments that have been acknowledged and some PDU segments that have notbeen acknowledged. Finally, boxes 18-31 represent RLC PDUs that have notyet been formed and transmitted.

VT(A) at box 7 represents the lower edge of the transmitting window 310and is the first RLC PDU that still requires full acknowledgement. VT(S)at box 18 represents the sequence number for the next new RLC PDU thatwill be transmitted. VT(MS) at box 23 is half the total sequence numberrange higher than VT(A) (16 in this 5-bit example) and represents theupper edge of the transmitting window 310. If VT(S) ever equals VT(MS),then no new RLC PDUs may be sent until VT(MS) increases.

A sequence number (SN) falls within the transmitting window ifVT(A)≦SN<VT(MS). If this condition is not satisfied, then the sequencenumber falls outside the transmitting window. 3GPP TS 36.322 specifiesthat an AM RLC transmitter shall not deliver to the Medium AccessControl (MAC) any RLC data PDU whose sequence number falls outside thetransmitting window. This implies that an RLC PDU that falls below thetransmitting window will not be retransmitted, even if a new negativeacknowledgement is received for it. In addition, if the transmittingwindow becomes full (i.e., VT(S) becomes equal to VT(MS)), the AM RLCentity may not transmit any new RLC PDUs until the lower edge of thetransmitting window is advanced. This condition is termed “windowstalling”, and 3GPP TS 36.322 specifies specific actions that are to betaken to address this situation if it ever arises.

At the receiving AM RLC entity, RLC PDUs may be received out of orderdue to lower layer hybrid automatic repeat request (HARQ)retransmissions. In addition, various RLC PDUs and/or RLC PDU segmentsmay be missing due to HARQ retransmission failure. A reception buffer ismaintained by the receiving AM RLC entity in order to recover theoriginal ordering of RLC PDUs.

3GPP TS 36.322 specifies that the state variables described in the tablein FIG. 4 are to be maintained by the receiving side of an AM RLC entityfor RLC PDU reordering purposes. The receiving window size(AM_Window_Size) is equal in length to half of the total sequence numberspace. AM RLC uses 10-bit sequence numbers, which results in anAM_Window_Size value of 512.

A specific sequence number SN falls within the receiving window ifVR(R)≦SN<VR(MR), and outside the receiving window otherwise. Allarithmetic operations and comparisons on RLC sequence numbers areperformed using an appropriate modulus corresponding to the configuredsequence number range (i.e., 1024 for 10-bit AM RLC sequence numbers)and a modulus base calculated as a function of certain state variablesand constants. This process is described in 3GPP TS 36.322.

FIG. 5 illustrates an example AM RLC receiving window 510 with therelevant state variables from the table in FIG. 4 also being shown inthe diagram. This example assumes a 5-bit sequence number purely forreasons of illustrative simplicity. Boxes 0-8 represent AMID PDUs thathave been completely processed by the reception buffer and released forRLC SDU reassembly. Boxes 10, 11, 12, 14, 15, 17, and 18 represent AMDPDUs that have been completely received but which are still being heldin the reception buffer. Boxes 9 and 13 represent AMID PDUs that havebeen partially received (i.e., at least one AMD PDU segment has beenreceived). Boxes 16 and 19-31 represent AMD PDUs that have not beenreceived. As shown in the diagram, VR(R) at box 9 represents the firstAMID PDU that has not been completely received, VR(H) at box 19represents the sequence number following the highest received orpartially received AMD PDU, and VR(MR) at box 25 represents the upperedge of the receiving window 510, which is a fixed distance (16 for this5-bit SN example) above the lower edge of the receiving window 510. TheAM RLC receiving window 510 is defined by the window's lower edge VR(R)and is pushed along when VR(R) increases in value. The receiving window510 cannot advance unless VR(R) advances.

Information about successfully and unsuccessfully received RLC PDUs isfed back from a receiving AM RLC entity to the transmitting AM RLCentity via a STATUS report or STATUS control PDU. FIG. 6 illustrates theformat of such a STATUS PDU 610, with a description of each field beinggiven in the table in FIG. 7. The length of a STATUS PDU is variable,depending upon how much acknowledgement information is included in it.

The ACK_SN field in the STATUS PDU is mandatory. Zero or more NACK_SNfields may optionally also be present within the STATUS PDU. EachNACK_SN field that is present may optionally have missing segmentinformation associated with it. The missing segment informationcomprises a segment offset start (SOstart) and a segment offset end(SOend) which indicate the byte numbers within the PDU corresponding tothe start and end of a missing segment of the PDU. If the receiving AMRLC entity is missing multiple non-contiguous segments of an AMD PDU, itmay include multiple NACK_SN fields with the same sequence number value,but with different segment offset fields. According to the rules forconstructing a STATUS PDU as described in 3GPP TS 36.322, multipleNACK_SN fields within the same STATUS PDU can be expected to be inascending order, and multiple NACK_SN fields with the same sequencenumber value can be expected to be in ascending byte segment order.

When a transmitting AM RLC entity receives a STATUS PDU, it interpretsthat all AMD PDUs with sequence numbers less than ACK_SN have beensuccessfully received, with the possible exception of any AMD PDUsand/or AMD PDU segments that are specifically identified via a NACK_SN(and optional segment offset information) as having not beensuccessfully received. That is, if a STATUS PDU does not list any dataPDUs or data PDU segments that were not successfully received, thetransmitting entity assumes that all data PDUs and data PDU segmentswith sequence numbers less than ACK_SN were successfully received. If aSTATUS PDU does list one or more data PDUs and/or data PDU segments thatwere not successfully received, the transmitting entity assumes that alldata PDUs and data PDU segments were successfully received with theexception of the listed data PDUs and/or data PDU segments. The listeddata PDUs and/or data PDU segments would then be retransmitted.

The wording in Section 5.2.3 of 3GPP TS 36.322 describing theconstruction of a STATUS PDU is as follows:

5.2.3 Status Reporting  <. . . removed text . . .> When constructing aSTATUS PDU, the AM RLC entity shall: for the AMD PDUs with SN such thatVR(R) <= SN < VR(MS) that has not been completely received yet, inincreasing SN order of PDUs and increasing byte segment order withinPDUs, starting with SN = VR(R) up to the point where the resultingSTATUS PDU still fits to the total size of RLC PDU(s) indicated by lowerlayer: for an AMD PDU for which no byte segments have been received yet:include in the STATUS PDU a NACK_SN which is set to the SN of the AMDPDU; for a continuous sequence of byte segments of a partly received AMDPDU that have not been received yet: include in the STATUS PDU a set ofNACK_SN, SOstart and SOend set the ACK_SN to the SN of the next notreceived RLC Data PDU which is not indicated as missing in the resultingSTATUS PDU.

It is also useful to reference the following contents of Section6.2.2.14 of 3GPP TS 36.322, which state how a STATUS report shall beinterpreted by the transmitting RLC entity.

6.2.2.14 Acknowledgement SN (ACK_SN) field Length: 10 bits. The ACK_SNfield indicates the SN of the next not received RLC Data PDU which isnot reported as missing in the STATUS PDU. When the transmitting side ofan AM RLC entity receives a STATUS PDU, it interprets that all AMD PDUsup to but not including the AMD PDU with SN = ACK_SN have been receivedby its peer AM RLC entity, excluding those AMD PDUs indicated in theSTATUS PDU with NACK_SN and portions of AMD PDUs indicated in the STATUSPDU with NACK_SN, SOstart and SOend.

The wording quoted above from Section 5.2.3 of 3GPP TS 36.322 can beparaphrased into simpler language as:

-   -   Begin with the lowest sequence numbered RLC PDU that has not yet        been received or which has been only partially received.    -   While there is still room in the STATUS report and there are        still transmitted PDUs that the receiver knows are missing or        partially missing:        -   If the current RLC PDU is completely missing then:            -   Include a NACK_SN in the STATUS report for that RLC PDU.            -   Advance to the next missing or partially missing RLC                PDU.        -   If the current RLC PDU has been partially received (i.e., at            least one segment has been received for that RLC PDU) then:        -   Include a NACK_SN, SOstart and SOend for the current RLC PDU            and current missing segment in that RLC PDU.        -   If the current RLC PDU has at least one more missing segment            that has not yet been described within the STATUS report            then:            -   Advance to the next missing segment within the same RLC                PDU.        -   Else:            -   Advance to the next missing or partially missing RLC                PDU.    -   Set ACK_SN to the sequence number of the next not received RLC        Data PDU which is not already indicated as missing in the        resulting STATUS PDU.

A problem might occur when an RLC PDU is missing multiple non-contiguoussegments, but there is insufficient room in the STATUS PDU to specifyall of the missing segments. In such a situation, the transmitting AMRLC entity may receive incorrect information about which RLC PDUsegments have been correctly received at the receiving AM RLC entity andwhich RLC PDU segments have not been correctly received.

FIG. 8 provides an illustrative example to demonstrate this potentialproblem. A transmitting entity made an initial transmission to areceiving entity, and the receiving entity sent the transmitting entitya first STATUS report specifying the PDUs and/or PDU segments that werenot successfully received. The transmitting entity then retransmittedthe specified PDUs and/or PDU segments, and the receiving entity sentthe transmitting entity a second STATUS report specifying the PDUsand/or PDU segments that were not successfully received in theretransmission. The table in FIG. 8 represents the status of a portionof the receiver buffer when this second STATUS report is generated. Inthis case, as a result of the first STATUS report, the RLC PDU 800 withSN=7 required an RLC retransmission and happened to be retransmitted asthree PDU segments. The second segment 820 of these three segments wasreceived correctly, but the first segment 810 and third segment 830 werenot.

When a STATUS report is triggered, it fills the available transmissionspace as much as possible. It is possible for a STATUS report to fill upbefore all the information that needs to be included is included. Inthis particular example, the STATUS report fills up after includingfeedback (NACK_SN, SOstart, SOend) for the first missing segment 810 ofthe RLC PDU 800 with SN=7. Consequently, there is insufficient room toinclude the feedback for the next missing segment 830 of the same RLCPDU 800 (with SN=7), which would require an additional set of NACK_SN,SOstart, and SOend fields. That is, the fact that the third segment 830was not successfully received is not included in the STATUS report.

The ACK_SN will be set to the “next not received RLC Data PDU which isnot indicated as missing in the resulting STATUS PDU” as described inSection 5.2.3 of 3GPP TS 36.322. Consequently, the resulting STATUSreport will contain:

ACK_SN=10¦NACK_SN=5¦NACK_SN=7/SOstart/SOend

That is, the ACK_SN indicates that the RLC PDU 850 with SN=10 is thenext not received RLC PDU that was not already indicated to be notreceived. The first NACK_SN indicates that the entire PDU 840 with SN=5was not received. The second NACK_SN indicates that the first segment810 of the PDU 800 with SN=7 was not received and gives the starting andending points of that segment. The fact that the third segment 830 ofthe PDU 800 with SN=7 was not received is not included in the STATUSreport because there is insufficient space in the STATUS report for thatinformation.

The transmitting RLC entity will interpret this received STATUS reportas described in Section 6.2.2.14 of 3GPP TS 36.322 (quoted above). Thatis, since no NACK_SN regarding the third segment 830 was included in theSTATUS report, the transmitting RLC entity will incorrectly assume thatthe third segment 830 was received correctly.

The consequence of this incorrect assumption depends on how thetransmitter manages the discarding of RLC PDUs and RLC PDU segments thatare indicated by a STATUS report to be successfully received. If thetransmitter does not discard RLC PDU segments that are indicated asreceived correctly (but only discards transmitted RLC PDUs once VT(A)(the bottom of the transmit window) has been advanced beyond thesequence number of that RLC PDU), then a subsequent STATUS report mayindicate the missing RLC PDU segment and this segment will beretransmitted. Hence, the situation will be recovered, albeit with someslightly longer delay.

However, if the transmitting RLC entity does discard RLC PDU segmentsthat (from the transmitter's viewpoint) have been indicated as receivedcorrectly, then the transmitter would be unable to retransmit thatmissing segment of the RLC PDU even if a subsequent STATUS reportrequests that it should be retransmitted, since the data would no longerbe available within the transmitter's retransmission buffer.Furthermore, the currently-specified error handling mechanisms would notdetect that a problem has occurred. The transmitter would likelyconsider that the STATUS report contains invalid values, as it containsa request to retransmit data that had previously been indicated ascorrectly received. The behavior specified in 3GPP TS 36.322 in thiscase is to discard the STATUS report. Also, if no retransmission canoccur, then the maximum number of retransmissions will not be reachedand Radio Link Failure will not be triggered. Hence, the consequence isthat the RLC protocol would stall with no means to recover.

Whether the transmitter discards transmitted PDUs is not specified bythe RLC protocol specification, but is left up to implementation.However, it is possible that a particular implementation could discarddata as soon as an RLC STATUS report indicating successful reception isreceived, so it may be desirable for the RLC protocol to be able tohandle this possibility and thus prevent the consequence describedabove. While this scenario may be expected to occur rarely, theconsequence if it does occur is serious.

In an embodiment, seven possible solutions to the identified problem areprovided. Proposed changes to 3GPP TS 36.322 corresponding to each ofthe seven possible solutions are also provided.

In a first solution, if the constructed STATUS report does not containinformation about all missing segments of an RLC PDU (which wouldcorrespond to the final NACK_SN in the STATUS PDU), then the ACK_SNfield is set equal to the sequence number of that RLC PDU, rather thanto the sequence number of the “next not received RLC Data PDU which isnot indicated as missing in the resulting STATUS PDU”. When thetransmitting RLC entity receives the STATUS report, it can deducewhether all missing segments of the RLC PDU with sequence number equalto the final NACK_SN in the STATUS report have been described within theSTATUS report by checking to see if the ACK_SN value is or is not equalto the final NACK_SN value.

In other words, when information about a missing segment is not includedin a STATUS report, the receiving RLC entity sets the ACK_SN to thesequence number of the PDU that has the missing segment. In the exampleof FIG. 8, the ACK_SN would be set to 7. The STATUS report would stillinclude a NACK_SN for that PDU, and that PDU is associated with the lastNACK_SN in the STATUS report. Therefore, when the sequence number of thePDU associated with the last NACK_SN is equal to the value of theACK_SN, the transmitting entity knows that the receiving entity did notsuccessfully receive all of the segments in the PDU associated with thelast NACK_SN.

One possible drawback of this method is that the transmitting RLC entitymay have to retain RLC PDUs in its retransmission buffer that haveactually been correctly received by the receiving RLC entity. The ACK_SNfield would be set to the sequence number of the RLC PDU that still hasunreported missing segments, and the correctly received segments withhigher sequence numbers that have been successfully received cannot beindicated as successfully received in the STATUS report. In the exampleof FIG. 8, as the ACK_SN would be set to 7, the PDUs with SN=8 and 9 arenot indicated as successfully received by this STATUS report. Asubsequent STATUS report would have to be transmitted in order toindicate successful reception of these PDUs.

To implement this solution, Section 5.2.3 of 3GPP TS 36.322 could berevised as follows:

5.2.3 Status reporting  <. . . removed text . . .> When constructing aSTATUS PDU, the AM RLC entity shall: for the AMD PDUs with SN such thatVR(R) <= SN < VR(MS) that has not been completely received yet, inincreasing SN order of PDUs and increasing byte segment order withinPDUs, starting with SN = VR(R) up to the point where the resultingSTATUS PDU still fits to the total size of RLC PDU(s) indicated by lowerlayer: for an AMD PDU for which no byte segments have been received yet:include in the STATUS PDU a NACK_SN which is set to the SN of the AMDPDU; for a continuous sequence of byte segments of a partly received AMDPDU that have not been received yet: include in the STATUS PDU a set ofNACK_SN, SOstart and SOend; if the final NACK_SN field in the STATUS PDUrefers to a partly received AMD PDU and there is a not received segmentof this AMD PDU which is not indicated in the STATUS PDU: set the ACK_SNto the SN of this partly received AMD PDU; else, set the ACK_SN to theSN of the next not received RLC Data PDU which is not indicated asmissing in the resulting STATUS PDU.

Alternatively, Section 5.2.3 of 3GPP TS 36.322 could be revised asfollows:

5.2.3 Status reporting  <. . . removed text . . .> When constructing aSTATUS PDU, the AM RLC entity shall: for the AMD PDUs with SN such thatVR(R) <= SN < VR(MS) that has not been completely received yet, inincreasing SN order of PDUs and increasing byte segment order withinPDUs, starting with SN = VR(R) up to the point where the resultingSTATUS PDU still fits to the total size of RLC PDU(s) indicated by lowerlayer: for an AMD PDU for which no byte segments have been received yet:include in the STATUS PDU a NACK_SN which is set to the SN of the AMDPDU; for a continuous sequence of byte segments of a partly received AMDPDU that have not been received yet: include in the STATUS PDU a set ofNACK_SN, SOstart and SOend set the ACK_SN to the SN of the first notreceived RLC Data PDU or RLC DATA PDU segment which is not indicated asmissing in the resulting STATUS PDU.

In a third alternative, Section 5.2.3 of 3GPP TS 36.322 could be revisedas follows:

5.2.3 Status reporting  <. . . removed text . . .> When constructing aSTATUS PDU, the AM RLC entity shall: for the AMD PDUs with SN such thatVR(R) <= SN < VR(MS) that has not been completely received yet, inincreasing SN order of PDUs and increasing byte segment order withinPDUs, starting with SN = VR(R) up to the point where the resultingSTATUS PDU still fits to the total size of RLC PDU(s) indicated by lowerlayer: for an AMD PDU for which no byte segments have been received yet:include in the STATUS PDU a NACK_SN which is set to the SN of the AMDPDU; for a continuous sequence of byte segments of a partly received AMDPDU that have not been received yet: include in the STATUS PDU a set ofNACK_SN, SOstart and SOend set the ACK_SN to the SN of the first notreceived RLC Data PDU which is not fully indicated as missing in theresulting STATUS PDU.

To further implement this solution, Section 6.2.2.14 of 3GPP TS 36.322could be revised as follows:

6.2.2.14 Acknowledgement SN (ACK_SN) field Length: 10 bits. The ACK_SNfield indicates the SN of the first not received RLC Data PDU or RLCDATA PDU segment which is not reported as missing in the STATUS PDU.When the transmitting side of an AM RLC entity receives a STATUS PDU, itinterprets that all AMD PDUs up to but not including the AMD PDU with SN= ACK_SN have been received by its peer AM RLC entity, excluding thoseAMD PDUs indicated in the STATUS PDU with NACK_SN and portions of AMDPDUs indicated in the STATUS PDU with NACK_SN, SOstart and SOend.

FIG. 9 illustrates an embodiment of a method for an acknowledged moderadio link control receiving entity to promote a retransmission of atleast a segment of a data protocol data unit according to this solution.At block 902, the receiving entity starts constructing a STATUS PDU,considering PDUs in increasing SN order. At block 904, it is determinedwhether the PDU is missing (i.e., not received). If the answer is “no”,the flow proceeds to block 906, where it is determined whether the PDUwas partially received. If the answer is “no”, the flow proceeds toblock 908, where it is determined whether there is space remaining inthe STATUS PDU and whether there are more missing or partially receivedPDUs to indicate in the STATUS PDU. If the answer is “yes”, the flowproceeds to block 910, where the next PDU is considered. The flow thenreturns to block 904. If the answer is “no” at block 908, the flowproceeds to block 912, where the ACK_SN is set to the SN of the next notreceived PDU. The flow then proceeds to block 914, where the STATUS PDUis sent.

If the answer is “yes” at block 904, the flow proceeds to block 916,where NACK information for this PDU is included in a STATUS PDU. Theflow then returns to block 906. If the answer is “yes” at block 906, theflow proceeds to block 918, where NACK information for each not receivedsegment of the PDU up to the size limit of the STATUS PDU is included ina STATUS PDU. The flow proceeds to block 920, where it is determinedwhether NACK information was included for all not received segments ofthe PDU. If the answer is “yes”, the flow returns to block 908. If theanswer is “no”, the flow proceeds to block 922, where the ACK_SN fieldin the STATUS PDU is set to the sequence number of the PDU. The flowthen proceeds to block 914, where the STATUS PDU is sent.

In a second solution, information for a partially received RLC PDU isonly included in a STATUS report if there is sufficient space in theSTATUS report to include information about all of the missing segmentsof that RLC PDU. If all of the missing segments cannot be described (dueto insufficient resource space), then a NACK_SN field is not includedfor that RLC PDU, and the ACK_SN field is set equal to the sequencenumber of that RLC PDU. This approach results in less information beingprovided to the transmitting RLC entity than does the approach describedin the first solution.

In other words, the receiving RLC entity sets the ACK_SN to the sequencenumber of the PDU that includes the missing segment as in the firstsolution. In this second solution, however, the STATUS report does notinclude a NACK_SN for that PDU.

To implement this solution, Section 5.2.3 of 3GPP TS 36.322 could berevised as follows:

5.2.3 Status reporting  <. . . removed text . . .> When constructing aSTATUS PDU, the AM RLC entity shall: for the AMD PDUs with SN such thatVR(R) <= SN < VR(MS) that has not been completely received yet, inincreasing SN order of PDUs and increasing byte segment order withinPDUs, starting with SN = VR(R) up to the point where the resultingSTATUS PDU still fits to the total size of RLC PDU(s) indicated by lowerlayer or it is not possible to add a full description of all missing AMDPDU segments for a partly received AMD PDU to the STATUS PDU: for an AMDPDU for which no byte segments have been received yet: include in theSTATUS PDU a NACK_SN which is set to the SN of the AMD PDU; for an AMDPDU that has been partly received: if all sets of NACK_SN, SOstart,SOend for this partly received AMD PDU fit within the STATUS PDU:include in the STATUS PDU a set of NACK_SN, SOstart and SOend for eachcontinuous sequence of byte segments of this partly received AMD PDU;else a NACK_SN field is not included for that RLC PDU. Set the ACK_SN tothe SN of this RLC PDU. If ACK_SN is not set yet, then set the ACK_SN tothe SN of the next not received RLC Data PDU which is not indicated asmissing in the resulting STATUS PDU.

FIG. 10 illustrates an embodiment of a method for an acknowledged moderadio link control receiving entity to promote a retransmission of atleast a segment of a data protocol data unit according to this solution.Blocks 902 through 916 are the same as in FIG. 9 and will not bedescribed again here. If the answer is “yes” at block 906, the flowproceeds to block 1018, where it is determined whether there is space toinclude NACK information for all not received segments. If the answer is“yes”, the flow proceeds to block 1019 where the NACK information forall the not received segments of the PDU is included in the STATUS PDUand then the flow returns to block 908. If the answer is “no”, the flowproceeds to block 1020, where NACK information for the not receivedsegments of the PDU is not included. The flow then proceeds to block1022, where the ACK_SN is set to the SN of the PDU.

In a third solution, the transmitting side of an RLC entity may keep anentire RLC PDU for possible retransmission when any portion of that RLCPDU is indicated within a STATUS report as not successfully received.This ensures that if the receiver did not completely describe all of themissing segments of an RLC PDU within a STATUS report, then thetransmitter will still have the data available for possibleretransmission in the future.

A slight modification to this approach would be that the transmittingside of an RLC entity only has to keep an entire RLC PDU for possibleretransmission when any portion of that RLC PDU is indicated within aSTATUS report as not successfully received and that RLC PDU correspondsto the final NACK_SN field in the STATUS report. Based on the currentprocedural description for constructing a STATUS report, any missingportions of any of the RLC PDUs corresponding to earlier NACK_SN fieldsin the STATUS report must have been completely described. Consequently,any of those RLC PDU segments that had been indicated as successfullyacknowledged by the receiver could be discarded by the transmitter. Apossible incomplete description of missing RLC PDU segments can onlyoccur for the RLC PDU whose sequence number corresponds to the finalNACK_SN field in the STATUS report.

Implementation of this solution might entail revisions to Section 5.2.1of 3GPP TS 36.322. Currently, this section is worded as follows:

5.2.1 Retransmission The transmitting side of an AM RLC entity canreceive a negative acknowledgement (notification of reception failure byits peer AM RLC entity) for an AMD PDU or a portion of an AMD PDU by thefollowing: STATUS PDU from its peer AM RLC entity. When receiving anegative acknowledgement for an AMD PDU or a portion of an AMD PDU by aSTATUS PDU from its peer AM RLC entity, the transmitting side of the AMRLC entity shall: if the SN of the corresponding AMD PDU falls withinthe range VT(A) <= SN < VT(S): consider the AMD PDU or the portion ofthe AMD PDU for which a negative acknowledgement was received forretransmission.  <. . . removed text . . .>

To implement the first alternative under this solution, Section 5.2.1 of3GPP TS 36.322 could be revised as follows:

5.2.1 Retransmission The transmitting side of an AM RLC entity canreceive a negative acknowledgement (notification of reception failure byits peer AM RLC entity) for an AMD PDU or a portion of an AMD PDU by thefollowing: STATUS PDU from its peer AM RLC entity. When receiving anegative acknowledgement for an AMD PDU or a portion of an AMD PDU by aSTATUS PDU from its peer AM RLC entity, the transmitting side of the AMRLC entity shall: if the SN of the corresponding AMD PDU falls withinthe range VT(A) <= SN < VT(S): consider the AMD PDU or the portion ofthe AMD PDU for which a negative acknowledgement was received forretransmission. The transmitting side of an AM RLC entity shall retainthe entire AMD PDU for possible retransmission when a negativeacknowledgement has been received for any portion of an AMD PDU. Noportion of an AMD PDU shall be discarded until the entire AMD PDU hasbeen positively acknowledged.  <. . . removed text . . .>

To implement the second alternative under this solution, Section 5.2.1of 3GPP TS 36.322 could be revised as follows:

5.2.1 Retransmission The transmitting side of an AM RLC entity canreceive a negative acknowledgement (notification of reception failure byits peer AM RLC entity) for an AMD PDU or a portion of an AMD PDU by thefollowing: STATUS PDU from its peer AM RLC entity. When receiving anegative acknowledgement for an AMD PDU or a portion of an AMD PDU by aSTATUS PDU from its peer AM RLC entity, the transmitting side of the AMRLC entity shall: if the SN of the corresponding AMD PDU falls withinthe range VT(A) <= SN < VT(S): consider the AMD PDU or the portion ofthe AMD PDU for which a negative acknowledgement was received forretransmission. The transmitting side of an AM RLC entity shall retainthe entire AMD PDU for possible retransmission when a negativeacknowledgement has been received for any portion of an AMD PDU and thesequence number of that AMD PDU corresponds to the final NACK_SN fieldin the STATUS PDU.  <. . . removed text . . .>

FIG. 11 illustrates an embodiment of a method for an acknowledged moderadio link control transmitting entity to promote the retransmission ofa segment of a data protocol data unit. At block 1110, the transmittingentity retains the entire data protocol data unit when a STATUS protocoldata unit received by the transmitting entity indicates that any portionof the data protocol data unit was not successfully received.

In a fourth solution, the receiving RLC entity indicates that not all ofthe missing segments for the RLC PDU corresponding to the final NACK_SNfield in the STATUS report have been described within the STATUS reportby setting the corresponding E1 field in the STATUS report to aspecified value, such as “1”. If the transmitting RLC entity detectsthat the E1 field equals the specified value, the transmitting entitydoes not immediately discard any portion of the RLC PDU indicated by thefinal NACK SN field. The receiving entity can then include informationabout the missing segments in the next STATUS report. The transmittingRLC entity waits for the next STATUS report to obtain more informationabout which remaining segments of that RLC PDU are still missing at thereceiver. It is important to note that this condition be recognized asrepresenting a valid STATUS PDU, and that the transmitting RLC entitymust not discard such a STATUS PDU as containing “invalid” values (asdescribed in Section 5.5.1 of 3GPP TS 36.322).

This solution might be used in conjunction with the third solutiondescribed above, where the transmitting side of an RLC entity keeps anentire RLC PDU for possible retransmission when any portion of that RLCPDU is indicated within a STATUS report as not successfully received.When the E1 field equals the specified value, the transmitting RLCentity could infer that the RLC PDU corresponding to the final NACK_SNfield has at least one missing segment that was not included in theSTATUS report. The transmitting RLC entity would know to retain thatentire RLC PDU for possible future retransmission.

To implement this solution, Section 5.2.3 of 3GPP TS 36.322 could berevised as follows:

5.2.3 Status reporting  <. . . removed text . . .> When constructing aSTATUS PDU, the AM RLC entity shall: for the AMD PDUs with SN such thatVR(R) <= SN < VR(MS) that has not been completely received yet, inincreasing SN order of PDUs and increasing byte segment order withinPDUs, starting with SN = VR(R) up to the point where the resultingSTATUS PDU still fits to the total size of RLC PDU(s) indicated by lowerlayer: for an AMD PDU for which no byte segments have been received yet:include in the STATUS PDU a NACK_SN which is set to the SN of the AMDPDU; for a continuous sequence of byte segments of a partly received AMDPDU that have not been received yet: include in the STATUS PDU a set ofNACK_SN, SOstart and SOend; if the final NACK_SN field in the STATUS PDUrefers to a partly received AMD PDU and there is a not received segmentof this AMD PDU which is not indicated in the STATUS PDU: set the E1field associated with this NACK_SN to 1; set the ACK_SN to the SN of thenext not received RLC Data PDU which is not indicated as missing in theresulting STATUS PDU.

FIG. 12 illustrates an embodiment of a method for an acknowledged moderadio link control receiving entity to promote a retransmission of atleast a segment of a data protocol data unit according to this solution.Blocks 902 through 920 are the same as in FIG. 9 and will not bedescribed again here. If the answer is “no” at block 920, the flowproceeds to block 1222, where the E1 field in the STATUS PDU is set to avalue that indicates that information about a segment of an RLC PDU isnot included in the STATUS PDU, and the ACK_SN is set to the SN of thenext not received PDU.

In a fifth solution, information for a partially received RLC PDU isincluded in a STATUS report only if there is sufficient space in theSTATUS report to include information about all of the missing segmentsof that RLC PDU. If all of the missing segments cannot be described (dueto insufficient resource space), then a NACK_SN field is included forthat entire RLC PDU rather than for the missing segments. The ACK_SNfield is set equal to the sequence number of the next missing (orpartially missing) RLC PDU. This will result in the transmitting RLCentity retransmitting the entire RLC PDU for which some portions werealready successfully received and some portions were not successfullyreceived. However, this is expected to be a fairly rare event thatshould have a negligible impact on resource utilization efficiency.

To implement this solution, Section 5.2.3 of 3GPP TS 36.322 could berevised as follows:

5.2.3 Status reporting  <. . . removed text . . .> When constructing aSTATUS PDU, the AM RLC entity shall: for the AMD PDUs with SN such thatVR(R) <= SN < VR(MS) that has not been completely received yet, inincreasing SN order of PDUs and increasing byte segment order withinPDUs, starting with SN = VR(R) up to the point where the resultingSTATUS PDU still fits to the total size of RLC PDU(s) indicated by lowerlayer: for an AMD PDU for which no byte segments have been received yet:include in the STATUS PDU a NACK_SN which is set to the SN of the AMDPDU; for an AMD PDU that has been partly received: if all sets ofNACK_SN, SOstart, SOend for this partly received AMD PDU fit within theSTATUS PDU: include in the STATUS PDU a set of NACK_SN, SOstart andSOend for each continuous sequence of byte segments of this partlyreceived AMD PDU; else, include in the STATUS PDU a NACK_SN which is setto the SN of the AMD PDU; set the ACK_SN to the SN of the next notreceived RLC Data PDU which is not indicated as missing in the resultingSTATUS PDU.

FIG. 13 illustrates an embodiment of a method for an acknowledged moderadio link control receiving entity to promote a retransmission of atleast a segment of a data protocol data unit according to this solution.Blocks 902 through 916 are the same as in FIG. 9 and will not bedescribed again here. If the answer is “yes” at block 906, the flowproceeds to block 1318, where it is determined whether there is space toinclude NACK information for all not received segments. If the answer is“yes”, the flow proceeds to block 1319 where the NACK information forall the not received segments of the PDU is included in the STATUS PDUand then the flow returns to block 908. If the answer is “no”, the flowproceeds to block 1320, where NACK information for this PDU is included.That is, the entire PDU is NACKed. The flow then proceeds to block 1322,where the ACK_SN is set to the SN of the next not received PDU.

The CPT (Control Packet Type) field in a STATUS PDU (as depicted in FIG.6 and described in the table in FIG. 7) is typically set to 000 toindicate the presence of a STATUS PDU, The remaining CPT values(001-111) are reserved. In a sixth solution, one of these reserved CPTvalues is used to indicate a STATUS report in which the RLC PDUcorresponding to the final NACK SN has missing segments that have notbeen fully described within the STATUS report. That is, this solution issimilar to the fourth solution, except that in this case, it is the CPTfield rather than the E1 field that indicates that the STATUS reportdoes not include information about one or more segments that were notsuccessfully received. For example, CPT=000 could indicate a normalSTATUS report, and CPT=001 could indicate a STATUS report that hasmissing information.

This solution might be used in conjunction with the third solutiondescribed above, where the transmitting side of an RLC entity keeps anentire RLC PDU for possible retransmission when any portion of that RLCPDU is indicated within a STATUS report as not successfully received.When the CPT field equals 001, the transmitting RLC entity could inferthat the RLC PDU corresponding to the final NACK SN field has at leastone missing segment that was not included in the STATUS report. Thetransmitting RLC entity would know to retain that entire RLC PDU forpossible future retransmission. Although it is proposed here thatCPT=001 is used to indicate this “special” STATUS report, any of theother reserved values (010-111) could be used equally as well.

Implementation of this solution might entail revisions to Section6.2.2.13 of 3GPP TS 36.322. Currently, this section is worded asfollows:

-   -   6.2.2.13 Control PDU Type (CPT) field    -   Length: 3 bits.    -   The CPT field indicates the type of the RLC control PDU. The        interpretation of the CPT field is provided in Table 6.2.2.13-1.

TABLE 6.2.2.13-1 CPT field interpretation Value Description 000 STATUSPDU 001- Reserved 111 (PDUs with this coding will be discarded by thereceiving entity for this release of the protocol)

To implement this solution, Section 6.2.2.13 of 3GPP TS 36.322 could berevised as follows:

-   -   6.2.2.13 Control PDU Type (CPT) field    -   Length: 3 bits.    -   The CPT field indicates the type of the RLC control PDU. The        interpretation of the CPT field is provided in Table 6.2.2.13-1.

TABLE 6.2.2.13-1 CPT field interpretation Value Description 000 STATUSPDU 001 STATUS PDU where the final NACK_SN RLC PDU has missing segmentsthat have not been fully described 010- Reserved 111 (PDUs with thiscoding will be discarded by the receiving entity for this release of theprotocol)

FIG. 14 illustrates an embodiment of a method for an acknowledged moderadio link control receiving entity to promote a retransmission of atleast a segment of a data protocol data unit according to this solution.Blocks 902 through 920 are the same as in FIG. 9 and will not bedescribed again here. If the answer is “no” at block 920, the flowproceeds to block 1422, where a Control Packet Type field in the STATUSPDU is set to a value that indicates that information about a segment ofan RLC PDU is not included in the STATUS PDU, and the ACK_SN is set tothe SN of the next not received PDU.

In a seventh solution, information for a partially received RLC PDU isalways included in a STATUS report. If there is sufficient space in theSTATUS report to include information about all of the missing segmentsof that RLC PDU, then all missing segments are included in the STATUSreport. If there is not sufficient space in the STATUS report to includeinformation about all of the missing segments of that RLC PDU, thenmultiple non-contiguous segments are consolidated into a smaller numberof segments. The consolidated segments are included as the missingsegments in the STATUS report. For example, when an RLC PDU is missingthree non-contiguous segments, say (SOstart1, SOend1), (SOstart2,SOend2), (SOstart3, SOend3), but there is only enough space to includeinformation about one missing segment, the missing segment that isreported in the STATUS report might be (SOstart1, SOend3). If there isenough space to include information about two missing segments, themissing segments that are reported in the STATUS report might be(SOstart1, SOend1), (SOstart2, SOend3). The ACK_SN field is set equal tothe sequence number of the next missing (or partially missing) RLC PDU.

In other words, the NACK_SN for a plurality of segments that need to beretransmitted will include a starting point at the start of the firstsegment that needs to be retransmitted and an ending point at the end ofthe last segment that needs to be retransmitted. Intermediary startingand stopping points might be included if there is space for thatinformation in the STATUS report. Any segments between the startingpoint and the ending point will be included in the NACK_SN and thereforewill be retransmitted regardless of whether or not they weresuccessfully transmitted in the previous transmission.

This might result in the transmitting RLC entity retransmitting only apartial RLC PDU. This may also lead to the retransmission of portions ofthe RLC PDU that may have already been successfully received by thereceiving RLC entity. However, this is expected to be a fairly rareevent that should have a negligible impact on resource utilizationefficiency.

To implement this solution, Section 5.2.3 of 3GPP TS 36.322 could berevised as follows:

5.2.3 Status reporting  <. . . removed text . . .> When constructing aSTATUS PDU, the AM RLC entity shall: for the AMD PDUs with SN such thatVR(R) <= SN < VR(MS) that has not been completely received yet, inincreasing SN order of PDUs and increasing byte segment order withinPDUs, starting with SN = VR(R) up to the point where the resultingSTATUS PDU still fits to the total size of RLC PDU(s) indicated by lowerlayer: for an AMD PDU for which no byte segments have been received yet:include in the STATUS PDU a NACK_SN which is set to the SN of the AMDPDU; for an AMD PDU that has been partly received: if all sets ofNACK_SN, SOstart, SOend for this partly received AMD PDU fit within theSTATUS PDU: include in the STATUS PDU a set of NACK_SN, SOstart andSOend for each continuous sequence of byte segments of this partlyreceived AMD PDU; else, consolidate the non-contiguous multiple segmentsinto fewer segments that can fit within STATUS PDU and report theseconsolidated segments in the STATUS report. set the ACK_SN to the SN ofthe next not received RLC Data PDU which is not indicated as missing inthe resulting STATUS PDU.

FIG. 15 illustrates an embodiment of a method for an acknowledged moderadio link control receiving entity to promote a retransmission of atleast a segment of a data protocol data unit according to this solution.Blocks 902 through 916 are the same as in FIG. 9 and will not bedescribed again here. If the answer is “yes” at block 906, the flowproceeds to block 1518, where it is determined whether there is space toinclude NACK information for all of the not received segments. If theanswer is “yes”, the flow proceeds to block 1519 where the NACKinformation for all the not received segments of the PDU is included inthe STATUS PDU and then the flow returns to block 908. If the answer is“no”, the flow proceeds to block 1520, where segments are consolidatedinto one segment, and NACK information for the consolidated segment isincluded in the STATUS PDU. The flow then proceeds to block 1522, wherethe ACK_SN is set to SN of the next not received PDU. A first number anda second number might be included in the STATUS PDU, the first numberbeing a segment offset start (SOstart) of a first segment of theplurality of segments, and the second number being a segment offset end(SOend) of a last segment of the plurality of segments.

The transmitting entity and receiving entity described above mightinclude a processing component that is capable of executing instructionsrelated to the actions described above. FIG. 16 illustrates an exampleof a system 1600 that includes a processing component 1610 suitable forimplementing one or more embodiments disclosed herein. In addition tothe processor 1610 (which may be referred to as a central processor unitor CPU), the system 1600 might include network connectivity devices1620, random access memory (RAM) 1630, read only memory (ROM) 1640,secondary storage 1650, and input/output (I/O) devices 1660. Thesecomponents might communicate with one another via a bus 1670. In somecases, some of these components may not be present or may be combined invarious combinations with one another or with other components notshown. These components might be located in a single physical entity orin more than one physical entity. Any actions described herein as beingtaken by the processor 1610 might be taken by the processor 1610 aloneor by the processor 1610 in conjunction with one or more componentsshown or not shown in the drawing, such as a digital signal processor(DSP) 1680. Although the DSP 1680 is shown as a separate component, theDSP 1680 might be incorporated into the processor 1610.

The processor 1610 executes instructions, codes, computer programs, orscripts that it might access from the network connectivity devices 1620,RAM 1630, ROM 1640, or secondary storage 1650 (which might includevarious disk-based systems such as hard disk, floppy disk, or opticaldisk). While only one CPU 1610 is shown, multiple processors may bepresent. Thus, while instructions may be discussed as being executed bya processor, the instructions may be executed simultaneously, serially,or otherwise by one or multiple processors. The processor 1610 may beimplemented as one or more CPU chips.

The network connectivity devices 1620 may take the form of modems, modembanks, Ethernet devices, universal serial bus (USB) interface devices,serial interfaces, token ring devices, fiber distributed data interface(FDDI) devices, wireless local area network (WLAN) devices, radiotransceiver devices such as code division multiple access (CDMA)devices, global system for mobile communications (GSM) radio transceiverdevices, worldwide interoperability for microwave access (WiMAX)devices, and/or other well-known devices for connecting to networks.These network connectivity devices 1620 may enable the processor 1610 tocommunicate with the Internet or one or more telecommunications networksor other networks from which the processor 1610 might receiveinformation or to which the processor 1610 might output information. Thenetwork connectivity devices 1620 might also include one or moretransceiver components 1625 capable of transmitting and/or receivingdata wirelessly.

The RAM 1630 might be used to store volatile data and perhaps to storeinstructions that are executed by the processor 1610. The ROM 1640 is anon-volatile memory device that typically has a smaller memory capacitythan the memory capacity of the secondary storage 1650. ROM 1640 mightbe used to store instructions and perhaps data that are read duringexecution of the instructions. Access to both RAM 1630 and ROM 1640 istypically faster than to secondary storage 1650. The secondary storage1650 is typically comprised of one or more disk drives or tape drivesand might be used for non-volatile storage of data or as an over-flowdata storage device if RAM 1630 is not large enough to hold all workingdata. Secondary storage 1650 may be used to store programs that areloaded into RAM 1630 when such programs are selected for execution.

The I/O devices 1660 may include liquid crystal displays (LCDs), touchscreen displays, keyboards, keypads, switches, dials, mice, track balls,voice recognizers, card readers, paper tape readers, printers, videomonitors, or other well-known input/output devices. Also, thetransceiver 1625 might be considered to be a component of the I/Odevices 1660 instead of or in addition to being a component of thenetwork connectivity devices 1620.

The following is incorporated herein by reference for all purposes: 3GPPTS 36.322.

In an embodiment, a method is provided for an acknowledged mode radiolink control receiving entity to promote a retransmission of at least asegment of a data protocol data unit. The method includes the receivingentity constructing a STATUS protocol data unit such that anacknowledged mode radio link control transmitting entity receiving theSTATUS protocol data unit retransmits the segment.

In an alternative embodiment, an acknowledged mode radio link controlreceiving entity is provided. The receiving entity includes a processorconfigured such that the receiving entity constructs a STATUS protocoldata unit such that an acknowledged mode radio link control transmittingentity retransmits a segment of a data protocol data unit.

In an alternative embodiment, a method is provided for an acknowledgedmode radio link control transmitting entity to promote theretransmission of a segment of a data protocol data unit. The methodincludes the transmitting entity retaining the entire data protocol dataunit when a STATUS protocol data unit received by the transmittingentity indicates that any portion of the data protocol data unit was notsuccessfully received.

In an alternative embodiment, an acknowledged mode radio link controltransmitting entity is provided. The transmitting entity includes aprocessor configured such that the transmitting entity retains an entiredata protocol data unit when a STATUS protocol data unit received by thetransmitting entity indicates that any portion of the data protocol dataunit was not successfully received.

While several embodiments have been provided in the present disclosure,it should be understood that the disclosed systems and methods may beembodied in many other specific forms without departing from the spiritor scope of the present disclosure. The present examples are to beconsidered as illustrative and not restrictive, and the intention is notto be limited to the details given herein. For example, the variouselements or components may be combined or integrated in another systemor certain features may be omitted, or not implemented.

Also, techniques, systems, subsystems and methods described andillustrated in the various embodiments as discrete or separate may becombined or integrated with other systems, modules, techniques, ormethods without departing from the scope of the present disclosure.Other items shown or discussed as coupled or directly coupled orcommunicating with each other may be indirectly coupled or communicatingthrough some interface, device, or intermediate component, whetherelectrically, mechanically, or otherwise. Other examples of changes,substitutions, and alterations are ascertainable by one skilled in theart and could be made without departing from the spirit and scopedisclosed herein.

1. A method for an acknowledged mode (AM) radio link control (RLC)receiving entity to promote a retransmission of at least a segment of adata protocol data unit (PDU), comprising: the receiving entityconstructing a STATUS PDU such that an AM RLC transmitting entityreceiving the STATUS PDU retransmits the segment.
 2. The method of claim1, wherein the construction of the STATUS PDU includes setting an ACK_SNfield in the STATUS PDU to a sequence number of the RLC PDU.
 3. Themethod of claim 2, wherein the STATUS PDU does not contain informationabout all missing segments of the RLC PDU.
 4. The method of claim 3,further comprising, omitting from the STATUS PDU a NACK_SN field for theRLC PDU.
 5. The method of claim 1, further comprising, a transmittingentity keeping an entire RLC PDU for possible retransmission when theSTATUS PDU indicates that at least a portion of the RLC PDU is notsuccessfully received.
 6. The method of claim 1, further comprising, atransmitting entity keeping an entire RLC PDU for possibleretransmission when the STATUS PDU indicates that at least a portion ofthe RLC PDU is not successfully received and the RLC PDU sequence numbercorresponds to a final NACK_SN field in the STATUS PDU.
 7. The method ofclaim 1, wherein the construction of the STATUS PDU comprises includingin the STATUS PDU a NACK_SN field for the entire data PDU.
 8. The methodof claim 1, wherein the construction of the STATUS PDU comprises settinga field in the STATUS PDU to a value that indicates that informationabout a segment of an RLC PDU is not included in the STATUS PDU.
 9. Themethod of claim 8, wherein the field is one of: the E1 field; and theControl Packet Type field.
 10. The method of claim 1, wherein theconstruction of the STATUS PDU includes consolidating a plurality ofsegments into one segment for the purpose of constructing the STATUSPDU.
 11. The method of claim 10, wherein the consolidation is performedby including a first number and a second number in the STATUS PDU, thefirst number being a segment offset start (SOstart) of a first segmentof the plurality of segments, and the second number being a segmentoffset end (SOend) of a last segment of the plurality of segments. 12.An acknowledged mode (AM) radio link control (RLC) receiving entity,comprising: a processor configured such that the receiving entityconstructs a STATUS protocol data unit (PDU) such that an AM RLCtransmitting entity retransmits a segment of a data PDU.
 13. Thereceiving entity of claim 12, wherein the construction of the STATUS PDUincludes setting an ACK_SN field in the STATUS PDU to a sequence numberof the RLC PDU.
 14. The receiving entity of claim 13, wherein the STATUSPDU does not contain information about all missing segments of the RLCPDU.
 15. The receiving entity of claim 14, further comprising, omittingfrom the STATUS PDU a NACK_SN field for the RLC PDU.
 16. The receivingentity of claim 12, further comprising, a transmitting entity keeping anentire RLC PDU for possible retransmission when the STATUS PDU indicatesthat at least a portion of the RLC PDU is not successfully received. 17.The receiving entity of claim 12, further comprising, a transmittingentity keeping an entire RLC PDU for possible retransmission when theSTATUS PDU indicates that at least a portion of the RLC PDU is notsuccessfully received and the RLC PDU sequence number corresponds to afinal NACK_SN field in the STATUS PDU.
 18. The receiving entity of claim12, wherein the construction of the STATUS PDU comprises including inthe STATUS PDU a NACK_SN field for the entire data PDU.
 19. Thereceiving entity of claim 12, wherein the construction of the STATUS PDUcomprises setting a field in the STATUS PDU to a value that indicatesthat information about a segment of an RLC PDU is not included in theSTATUS PDU.
 20. The receiving entity of claim 19, wherein the field isone of: the E1 field; and the Control Packet Type field.
 21. Thereceiving entity of claim 12, wherein the construction of the STATUS PDUincludes consolidating a plurality of segments into one segment for thepurpose of constructing the STATUS PDU.
 22. The receiving entity ofclaim 21, wherein the consolidation is performed by including a firstnumber and a second number in the STATUS PDU, the first number being asegment offset start (SOstart) of a first segment of the plurality ofsegments, and the second number being a segment offset end (SOend) of alast segment of the plurality of segments.
 23. A method for anacknowledged mode (AM) radio link control (RLC) transmitting entity topromote the retransmission of a segment of a data protocol data unit(PDU), comprising: the transmitting entity retaining the entire data PDUwhen a STATUS PDU received by the transmitting entity indicates that anyportion of the data PDU was not successfully received.
 24. The method ofclaim 23, wherein the transmitting entity retains the entire data PDUonly when the data PDU corresponds to the final NACK_SN field in theSTATUS PDU.
 25. An acknowledged mode (AM) radio link control (RLC)transmitting entity, comprising: a processor configured such that thetransmitting entity retains an entire data protocol data unit (PDU) whena STATUS PDU received by the transmitting entity indicates that anyportion of the data PDU was not successfully received.
 26. Thetransmitting entity of claim 25, wherein the transmitting entity retainsthe entire data PDU only when the data PDU corresponds to the finalNACK_SN field in the STATUS PDU.